GlusterFS vs. CephFS性能对比研究（一）

对一个分布式文件系统而言，有一些特性是必须要满足的，否则就无法有竞争力。这些特性概述如下：

·应该符合 POSIX 的文件接口标准，使该系统易于使用。

·数据一致性：只要客户数据写入成功，无论何时读，得到内容应该一致。

·数据持久化：具有一定的安全机制，保证数据不会丢失。

·可用性：保证系统部分模块异常时，总体仍能正常提供服务。

·伸缩性：通常为可扩展性，当数据压力逐渐增长时能顺利动态扩容。

同时，基于分布式系统设计目标，还需提供强大的性能和强大的负载与容量均衡能力。

可以说分布式系统的设计是为达到高性能，高容量和高可扩展性。为了在此基础上解决持久化与可用性问题，分布模式中又会引入数据冗余概念。随之将在正常，扩容与异常等状态下产生一系列问题，这些问题通常围绕一致性，可用性与性能三项。不同的分布式系统分布模式与对此三项的取舍平衡有所差异，这些差异最终导致不同分布式系统在各种状态下的不同表现。

本文旨在对比GlusterFS与CephFS二者社区原生系统在实现上述特性时产生的差异与其表现结果。对比版本分别为Gluster 3.12.x与Ceph 12.2.x，基于上述问题，本文对比维度选择分布模式以及弹性扩展和异常处理时的表现。

分布模式

GlusterFS使用了完全去中心化结构，服务端管理单元glusterd只需要负责协调弹性，逻辑卷增删等管理。而在正常工作时服务端只需要存储单元brick，存储单元对等存储了配置信息。GlusterFS的客户端承担数据分布，冗余，平衡，自修复，配额管理等等功能，而存储单元逻辑承担较少。

CephFS在正常使用中除了存储单元OSD，还必须有元数据管理单元MDS来提供索引等元数据服务。同时还需要监控单元MON使用Paxos算法来维护整个集群OSD，MDS等Map信息的版本，以此保障一致性。在长时间MDS或MON不可用时，CephFS的客户端是无法单独与OSD完成请求交互的。在CephFS中，相对来说客户端承担责任较少，而存储单元承担逻辑较多。

如下图对比GlusterFS与CephFS，CephFS虽然MON和MDS都有避免单点故障的机制，但仍不可避免对可用性造成了影响，故首先在去中心化上显然GlusterFS更胜一筹。

分布

GlusterFS客户端挂载逻辑卷，逻辑卷包含了各自分布与冗余的逻辑。GlusterFS采用一致性哈希算法作为分布和索引的基准。对一个文件，其使用Davies-Meyer算法计算一个有范围的随机哈希值，输入参数为文件名。而文件的父目录会在目录创建时根据存储单元brick权重划分此目录在各个存储单元brick上的哈希分布区间，文件哈希值落在哪个范围内，最终定位就在哪个存储单元中。

     GlusterFS分布DHT用Davies-Meyer算法计算哈希的随机性来保证客户端同一个目录的子文件分布到各个存储单元中的随机性。同时客户端不同目录分布区间不同来保证不同目录下同一文件也可分布至不同存储单元。

CephFS资源池包含了分布与冗余的逻辑，资源池基于Ceph的Crush规则。Crush算法本质也是利用哈希计算获得随机分布。Crush为了保证分布的弹性，将存储单元OSD在集群中唯一id号作为参数与文件名共同参与哈希计算，根据文件对每个存储单元OSD计算所得随机数（Ceph称之为“长度”）大小比较来决定落入哪个OSD中，最长的OSD将取胜获得此文件。

CephFS使用数据归置组PG的概念避免了百亿数量级文件每个都要对所有OSD进行计算。文件先通过哈希计算取模映射到PG中，资源池中每个PG通过唯一的id替代文件名参与哈希计算。计算得出结果变为PG当落入哪个OSD中。

PG作为资源池的固有概念，在一个资源池中个数是基本不变的。为了保证分布，每个OSD上的PG数量不宜过少。CephFS通过PG设置在保证了数据归置的同时仍维持了分布。

除此之外，CephFS对大文件进行切割操作，将一个大文件映射至不同PG中，每个切割块根据顺序号与大文件名进行哈希计算。

冗余

在GlusterFS中分布与冗余逻辑是严格划分的，其存在上下层级结构，客户端维护了这一逻辑。基于一致性要求，从客户端冗余层到服务端存储单元写请求采用同时发出收到所有确认后才完成的模式；而读请求将负载均衡到所有存储单元上。考虑到对于GlusterFS而言，几个存储单元总是相对静态得被绑定提供冗余，为了利用起所有存储单元的磁盘利用率，这是正常逻辑。

CephFS如上文所述冗余已包含在资源池的Crush逻辑中，即是将冗余副本编号或是纠删码编号作为第三个参数参与哈希分布计算，如下图所示。

CephFS客户端总是对主副本（无论副本还是纠删码都有主）所在存储单元发起读写请求。为了维持一致性，由主副本所在OSD将写入同步至其他从副本所在OSD，而读请求只有主副本所在OSD可以完成。考虑到CephFS中，每个PG主从副本总是随机分布到各个OSD中，其不存在GlusterFS一样严格的存储单元专用和冗余绑定障碍。不同文件读压力其实仍然是分布到各个OSD中的，同样CephFS大文件切割机制也有利于压力分散。

权重设置

GlusterFS可以通过人工修改目录在每个存储单元brick上的哈希分布区间（修改目录扩展属性）来改变负载均衡，这相当于brick权重设置。而CephFS中通过修改存储单元OSD的权重来间接改变负载均衡，这是因为权重其实作为第四个参数参与了PG的分布计算从而影响了每个存储单元OSD对每个PG“长度”胜出的概率。在权重设置上，GlusterFS与CephFS都是动态且便利的。

容错域

GlusterFS由于分布与冗余的上下层级结构，在容错域划分上使用较为单一。冗余绑定的几个brick所落层级就定性了容错域。

CephFS的Crush提供了更弹性的容错域划分。Crush提供了多个等级（比如机房，机架，主机等）的集群层级结构。其实际意义是PG在映射OSD时，通过哈希“长度”比较将不直接将OSD号参与计算而是层层往下寻找映射。而每个层级都能作为容错域设置。例如下图假设现在PG副本1已选择了OSDy，要选出下一副本，Crush规定了可以将host4屏蔽在其他host选出，也可以将rack2屏蔽，要在其他rack选出，甚至可以设置屏蔽room1，以达到双副本总是分布在不同房间的效果。

对比列表

弹性扩展

数据迁移量

分布式系统扩容不是简单地将新文件都写入新存储节点或新存储单元，这样完全损失了旧有硬件的带宽和计算能力，失去了分布的意义。故通常情况下分布式系统扩容必定是将新存储单元与节点加入旧有分布模式逻辑下，经此过程为了继续维护容量和负载均衡，通常都将进行旧有数据向新存储区域的迁移。

由上一节可知GlusterFS和CephFS分布模式都依靠逻辑卷或逻辑资源池确立，其有各自的动态迁移逻辑。在一个大容量集群中，这个过程的数据迁移量将非常庞大，其直接影响了迁移持续时间与迁移时的性能。

GlusterFS在完成目录哈希区间重新分布开启迁移后，将会通过深度优先遍历目录树的方式处理需要迁移的文件。对一个目录而言其文件分布区间将发生如下改变，可以清晰看到除了新存储单元4迁入文件外，存储单元1，2，3之间也将产生部分迁移。以此例来讲将产生超过四分之一数据的迁移。

     CephFS由前文知将让每个PG对新存储单元计算随机“长度”并与其对旧有存储单元的三个随机“长度”进行比较。以概率而言，新存储单元4将有四分之一的PG在随机“长度”上胜过旧有存储单元1，2，3，这些PG将连同其归置的数据一起迁入新存储单元4，如图所示整个迁移过程仅产生四分之一数据迁移。

理解两种分布式系统对哈希算法的不同运用，可以发现，CephFS在扩容中总是能保证只迁移应落于新存储单元的数据，而此数据量结果也符合新存储单元权重，这在缩容情况中也适用。这是因为存储单元作为哈希算法参数参与计算并比较结果，新存储单元的“长度”大小不会影响旧有存储单元之间“长度”的比较结果。

对比CephFS，GlusterFS数据迁移显得较为不合理，这是计算简单带来的负作用，对此现象，GlusterFS将在未来通过虚拟节点改进。

虚拟节点的引入实际上是通过对一致性哈希算法计算结果增加一层映射关系。如图所示，首先将哈希区间绑定固定个数虚拟节点，其次将所有虚拟节点映射至不同存储单元，存储单元各目录扩展属性中取代哈希区间将记录拥有的虚拟节点。而在扩容时，只需部分虚拟节点迁入新存储单元来避免旧有存储单元间数据的迁移。若实现，则在数据迁移量方面降低到接近CephFS。

如下图所示扩容时虚节点映射改变，这个方法目前GlusterFS还尚未引入。同样如图，这种方法带来的文件定位复杂度提高和数据不平衡程度也有待检验。

弹性程度

众多分布式系统在扩容时都会面临一个问题，将新存储单元和节点加入旧有分布模式下，可能产生故障域级别或负载均衡方面的变化。大多数人为使用过程一定是尽可能地保证这两项不会改变，这通常造成了扩容粒度的限制。

GlusterFS为了维持故障域级别和负载均衡，分布层面会希望扩容增加的存储单元是冗余份数的倍数。例如双副本模式，如图所示，总是希望能新增偶数个存储单元；而纠删码模式，例如4:2时，会希望能有6为倍数的存储单元扩容。

CephFS从扩容粒度来讲，无论扩展多少存储单元和节点都是平滑处理。例如下图双副本模式，部分PG副本1迁入新存储单元，部分PG副本2迁入新存储单元。

平衡影响

CephFS尽管在扩容过程中维持理论上的负载均衡，但在实际应用情况中，由于CephFS使用PG这种归置组逻辑，而PG数量是不会自动动态增长的；若是在原本负载均衡的集群上一次扩容2倍甚至更多的节点，这会造成每个存储单元实际掌握的PG数量大大减少，放大每个存储单元PG数量不平衡的程度。PG数量不均衡直接造成了数据负载不均衡。这也是CephFS对每个存储单元有最小建议PG数的由来，扩容过大，显然会导致PG数小于这个建议数量。

对此问题CephFS一般不会采用增大PG数量方式，而是在扩容后对存储单元重新设置权重来人工平衡。

对于GlusterFS来讲，其没有归置组的概念，还使用客户端不同目录来更好均衡，所以扩容造成的平衡影响几乎没有。（若GlusterFS如上所述采用虚拟节点作为哈希区间归置组可能将面临相同的问题，但其通过不同目录不同映射就能有效缓解。）

迁移过程可用性

GlusterFS采用三个步骤完成迁移的整个过程。其一扩容完成，此时新创建的目录将有新的哈希区间分配，新目录子文件将分布到所有存储单元，而旧有目录与子文件不变；其二修复目录，将新存储单元包含入重新计算各目录哈希区间分布；其三数据迁移，通过深度优先遍历处理需要迁移的文件。整个过程总是能保证冗余数据量，以保证可用性。

CephFS在实践中，扩容受容错域影响。如下图所示，一次扩容容错域个数（例如主机个数）超过资源池最小副本数设置，不可避免地使PG重新分布后达不到最小副本数要求。可能导致可用性的下降，要等待数据迁移完成恢复。

写入保障

集群扩容有时发生在集群容量接近满负荷时，在一些大压力环境下，集群扩容后集群容量大大增加，但实际数据迁移速度可能在一段时间内不及新增数据速度，此时新数据写入如何继续保障?

GlusterFS存在一套自动处理容量均衡的机制。例如一个新文件经计算将落入旧有存储单元，而旧有存储单元容量不足，此时会为文件创建一个链接至其实际落入的存储单元，之后读写请求将通过链接转发。

CephFS在存储单元容量满时只能进入写入保护模式，其写入操作会完全block，只有在数据迁移后，数据量near full以下时才可以继续写入。

对比表

异常处理

以发生频率来说，分布式系统最常见的异常情况可分为存储单元异常，主机异常与网络异常，这三类异常都可称为分区问题。

CAP原理揭示在分区问题发生时，通常分布式系统仍需要提供正常服务,而在此时高可用性和强一致性是无法同时保证。可用性要求所有客户端请求都在一定时间内能够完成，一定程度上衡量异常时性能；一致性要求读操作总能读到前一个写操作结果，即是说分布式环境中，多点冗余读出数据是否总是最新的一致数据。

GlusterFS的去中心化结构使其在异常产生时，可用性得到了保障。以双副本举例，在一个存储单元异常后，客户端io仍然能够正常访问另一个存储单元不受影响。另外由于GlusterFS强烈的去中心化特性，其每个存储节点主机都是等价承担冗余工作的，考虑故障域划分也不会将双副本分布同一主机，所以单个主机异常和单个存储单元异常在副本模式下是同一类故障，处理方式类似。

GlusterFS在处理网络分区问题时也使用类似逻辑，如图所示网络割裂情况，两副本甚至可以各自负载不同读写操作。

纵观GlusterFS两种情况处理逻辑，都会产生数据一致性的问题。GlusterFS在集群正常时总是令写入请求同时写双副本完成后才算完成，这是符合强一致性要求的。

而在客户端无法连接一个存储单元时，GlusterFS会退而求其次选择提供高可用性，继续接受读写请求。可以预见如网络波动，割裂，不同时间段存储单元分别提供单独服务等等状况都会导致两个副本间数据的不一致，甚至在网络波动过程中，客户端1写入的数据暂时无法从客户端2读取，这显然不符合强一致性要求。

GlusterFS为保证高可用采取求取最终一致性的做法，最终一致性简单理解需要一个时间窗口来使一致性最终达成。GlusterFS通过ChangeLog来达到副本间最终的一致。GlusterFS中，一个文件在副本间通过各自的ChangeLog确认彼此属于wise还是fool从而互相恢复。

然而在上述一些异常情况中，最终正常时可能双副本都认为自己是wise的，它们判断不能互相覆盖，而是告警需要人工来确认正确数据。这就是GlusterFS在实际使用中产生的脑裂问题，此问题在网络波动中最为常见。

GlusterFS其实有在异常情况下防止脑裂机制Quorum。Quorum机制简单来说就是设置最小写成功的副本数，比如3副本最小写成功2个，否则返回错误。这在保证了失去1副本时可用性的同时，使正确写入的副本ChangeLog有数量上的优势而在数据恢复过程中wise胜出。而Quorum对于双副本只能选择主副本正常可接受写入才能防止脑裂问题，这对双副本来说等于完全失去可用性，故大多数情况是不可能在双副本上开启Quorum的。所以双副本情况下最终总是可能产生脑裂问题。这说明某些冗余模式极端情况下，GlusterFS只能维持弱一致性。

CephFS为保证一致性提供了完整的机制。上文已介绍CephFS无论副本还是纠删码模式对于写操作都只会通知主副本。在主副本记录PGLog保存PG中数据变化后，才进行多副本的一致性写入过程，此过程从副本也会记录PGLog；而CephFS读操作永远只通过主副本读取。所以只要保证主副本总是拥有最权威PGLog就能达成强一致性。

PGLog在一定程度上可以说是GlusterFS中文件ChangeLog的归置组化，但其通过如图四个步骤防止了CephFS出现类似GlusterFS的脑裂问题，并继续维护一致性。

首先无论PG主从哪个副本失效，一段时间后PG将重新分布，在随后开始数据迁移以保证冗余度不变来维持正确PGLog数量优势；其次主副本失效，若重新分布后选择的新主未完成数据迁移，将有临时分布选取从副本代替主接受读写请求；然后无论是否开始迁移，迁移完成与否，对于冗余度不足的PG总是标记降级，PG中冗余度不足的对象写入受限；最后MON的Paxos算法维护了PGMap版本的顺序性，使任何时期的主副本都能获取PGMap的所有变化从而能从所有经历过的OSD获取PGLog拼合权威PGLog完成自身恢复。

在维护异常前中后强一致性过程中，可以发现CephFS大部分时候是损失了高可用性的，尤其在主副本需要恢复或副本降级时。涉及对象的IO操作会入队列等待，对于客户端来说，会有一些IO Block现象。

同时MON中Paxos算法对强一致性维护起决定作用，故MON通信等异常时，集群为维护强一致性应当停止服务，可用性大大受限。故MON本身通过Quorum来避免这种尴尬情况，然而在最小份数不足时MON无法继续为客户端提供各类Map更新。如下图所示，网络分区，网络波动时MON总是只能为一边继续提供可用性。

     而MDS由于热备的存在，一般异常现象例如MDS主机异常的影响是比较小的，但同样在网络分区，网络波动时可能需要冷备恢复，这时可用性也会受到影响。

对比表

结论

通常一个分布式文件系统设计无法在一开始就面面俱到，其架构设计必定基于对前述特性的一点或几点的强烈需求。对比GlusterFS和CephFS后不难发现，GlusterFS在设计上更多考量了分区容忍与可用性，还有线性扩展的能力，其去中心化意识较之CephFS更为明显；而CephFS从设计之初就确立了一套复杂的Paxos算法与Crush规则相辅相成的机制，在一致性问题考量上更为严密。基于二者社区版本做功能开发与性能优化时应当充分考虑其特性并进行缺陷的补足。

附

另附GlusterFS 3.12.x与CephFS 12.2.x在一些加分功能上的对比表，作为深入开发的参考。

关于“Linux宝库”微信公众号：

欢迎关注"Linux宝库"微信公众号，这里每天发布最新的开源人物和开源事件。谨以此号记录Linux和开源业界的点点滴滴，为开源爱好者和从业者点亮人生。

- 责任编辑：ArthurGuo -- END -